Distributed process systems, in which the technique of distributing an application execution is used, are similar to the traditional multi-user systems such as Unix. From a graphics standpoint, the distributed process systems are similar to X-Windows. The technique of distributing an application execution is called Distributed Application Presentation (DAP).
In a DAP system, an application server provides application execution services to network users rather than running the application at the user's workstation. When the application runs, the application server intercepts the application user's interface (e.g., the display screen, keyboard, and mouse) data and transmits/receives this data to/from a small client (user) program running at the user's workstation. More advanced DAP systems operate in a highly integrated network environment in which an application server technology is coupled with local area network (LAN) or wide area network (WAN) transport systems as shown in FIG. 1. The host computer 300 is coupled to LAN/WAN transport system 304. This coupling, that allows the LAN/WAN network administrator to more widely distribute the services of session manager 301 and application servers 302 to user workstations 305, requires that the session manager be able to support the simultaneous execution of multiuser applications including support of workstation interfaces such as: keyboard, mouse, and display screen. The most prevalent use of application servers is in dial-in remote access DAP systems.
When running an application on an application server, the user is not actually executing the application code on the user's local workstation. Therefore, in order to make the application server's remoteness transparent, the user workstation storage disks and printers must be accessible by the application server.
The workstation includes the following capabilities:
(1) a protocol for transmission of display screen, keyboard, mouse, file, and printer data; PA1 (2) a layered distribution architecture for transmission of the protocol packets; PA1 (3) a client program that can run on the user workstation for protocol interpretation; and PA1 (4) a configuration application for configuring the application distribution protocol stack for accommodating a variety of transport media and client types. When the workstation is operating as a virtual computer, it is running a client program which transmits and receives Windows-type object level protocol packets. The workstation also handles protocol packets for controlling printing and storage disk operation. If the workstation is a fixed function system, such as an ASCII text terminal, the protocol of the terminal is used. PA1 (1) full-screen text presentation, PA1 (2) Windows application screen presentation, PA1 (3) keyboard and mouse input, PA1 (4) session control, PA1 (5) framing of data for asynchronous connections, PA1 (6) error detection and recovery, PA1 (7) compression and encryption hooks, PA1 (8) file system redirection, PA1 (9) print redirection, and PA1 (10) multiple generic virtual channels. PA1 (1) connection initialization; PA1 (2) workstation (client) interface and display screen control; PA1 (3) workstation keyboard and mouse input to the application server; and PA1 (4) workstation keyboard light emitting diode (LED) display control. PA1 (1) command and object specific compression; PA1 (2) outboard complex clipping and complex curve drawing; PA1 (3) efficient caching of Windows objects (bitmaps, brushes, glyphs, and pointers); and PA1 (4) run-length encoding. PA1 (1) establishing and maintaining configuration data; PA1 (2) loading required protocol components; PA1 (3) running a polling loop; and PA1 (4) presenting a local user interface. PA1 (1) MODULE.INI that lists the protocol stack components; PA1 (2) APPSRV.INI that describes the application server configuration; PA1 (3) MODEM.INI that describes the modem management strings; and PA1 (4) WFCLIENT.INI that lists the user configurations. PA1 (1) clib, a C-language run-time library subset; PA1 (2) cfg, libraries for configuration and standard operations such as loading and linking; PA1 (3) ini, functions for access of .INI style parameters; PA1 (4) video, keyboard, mouse, timer, and parallel port libraries for access to these hardware components; PA1 (5) xms, extended memory allocation libraries; and PA1 (6) logging, functions for standard logging and tracing facilities. PA1 (a) Load() for loading and linking a driver into the protocol stack; PA1 (b) WdUnload() for unlinking and unloading a driver from the protocol stack; PA1 (c) WdOpen for opening and initializing a driver; PA1 (d) WdClose for closing a driver; PA1 (e) WdInfo for querying driver information; PA1 (f) WdPoll for getting status and giving control to drivers in the protocol stack; PA1 (g) WdQueryInformation for querying modem status, mouse information, last error, and statistics; and PA1 (h) WdSetInformation for connecting, disconnecting, setting or killing a focus. PA1 (a) a Compression PD for compressing and decompressing of raw data; PA1 (b) a Reliable PD for error handling for unreliable transports such as IPX and Async; PA1 (c) a Framing PD for framing of stream type data from Async and TCP transport services into packets; PA1 (d) a Modem PD for managing the establishment of a modem connection; and PA1 (e) an Encryption PD for encrypting data. PA1 (a) Load () for loading and linking a driver into the protocol stack; PA1 (b) WdUnload()/PdUnload() for unlinking and unloading a driver from the protocol stack; PA1 (c) WdOpen/PdOpen for opening and initializing a driver; PA1 (d) WdClose/PdClose for closing a driver; PA1 (e) WdInfo/PdInfo for querying driver information; PA1 (f) WdPoll/PdPoll for getting status and giving control to drivers in the protocol stack; PA1 (g) PdWrite for writing data; PA1 (h) WdQueryInformation/PdQueryInformation for querying modem status, mouse information, last error, or statistics; PA1 (i) WdSetInformation/PdSetInformation for connecting, disconnecting, setting and killing focus. PA1 (a) an IPX (Internet Packet Exchange) TD is a NetWare LAN communication protocol for moving data between server and/or workstation programs running on different network nodes; PA1 (b) an SPX (Sequenced Packet Exchange) TD is an enhanced set of commands implemented on top of IPX for creating a true transport layer interface; PA1 (c) a TCP/IP (Transmission Control Protocol) TD is an Internet protocol suite providing reliable, full duplex, stream service. PA1 (d) a NetBIOS (Network Basic Input/Output System) TD is an application programming interface for data exchange between a server and/or workstation programs running on different network nodes; and PA1 (e) an Async TD is the standard interface to an RS-232 type asynchronous transport service. PA1 (a) client printer mapping for allowing a printer device on the Application Server to be redirected to a printer on the client computer; PA1 (b) client drive mapping for redirecting drive letters on the Application Server to drive letters that exist on the client computer; and PA1 (c) Thinwire presentation protocol for operating the WD protocol as a virtual channel. PA1 a) at the application server, encoding each glyph in the string of glyphs by assigning to each unique glyph (i.e. the same character code, size, font, and style, but not necessarily the same color) a corresponding unique identification code (IDC); PA1 b) transmitting a compressed string of data that is generated by sequentially transmitting each glyph in the string of glyphs together with each glyph's corresponding IDC if it has not been previously transmitted, otherwise only transmitting the corresponding IDC; PA1 c) at the workstation, receiving the compressed string of data and storing each glyph in accordance with its assigned IDC; and PA1 d) regenerating the original string of glyphs by using the IDCs in the order received for retrieving the stored glyphs.
FIG. 2 shows the major workstation protocol layers of a commercial application server system called "WinFrame.TM." manufactured by Citrix Systems, Inc. of Coral Springs, Fla. The WinFrame.TM. workstation is called "WinStation". The present invention has been implemented in a system of this type and hence the WinFrame.TM. system will be used as a basis for describing the invention by way of explanation only and not by way of limitation of the scope of the invention. Referring to FIG. 2, the three major sets of protocol layers are: the WinStation Driver (WD) set 10 acting as the work-station data stream manager that includes ICA, the protocol used for communication of screen, and mouse and keyboard updates, between the application server and the workstation; the protocol driver (PD) set 20 of optional communications protocol layers such as data compression, encryption, reliability (error control), and modem control; and transport drivers 21 for connecting the workstation to the connection (transport) medium.
ICA, a line protocol used to communicate Windows application presentation data with the application server over a low bandwidth connection, includes protocol definition for the following capabilities:
ICA uses packet communication techniques for communications between the application server and the workstation. The packet, shown in FIG. 3, can be prefixed by optional preambles, negotiated when a connection is established, for managing the transmission of the packet. The nature of the transmission medium (e.g., LAN or Async) and user defined options (e.g., compression, encryption) determine the total packet definition, but the overall packet format is as shown in FIG. 3. The labeled segments are defined as follows:
Frame Head--optional preamble protocol header for framing stream oriented transport data;
Reliable--optional preamble protocol header in packet for transmission error detection and correction;
Encrypt--optional preamble protocol header for managing encrypted data;
Compress--optional preamble protocol header for managing compressed data;
COMMAND--ICA command byte marking the beginning of the base ICA protocol packet;
COMMAND DATA--optional data bytes associated with the specified COMMAND segment that can include virtual channel protocol packets; and
Frame Trail--optional protocol trailer (postamble) for framing ASYNC transport data.
Only the COMMAND byte is always present in the packet. The preambles and postamble are dependent upon the transport used and the initialization negotiations.
The ICA COMMANDS include control commands and virtual channel commands.
The ICA control COMMAND packets manage the connection of the workstation to the application server and the server relationship to workstation interface. The COMMAND packets include information on:
The ICA virtual channel COMMAND packets provide multiplexed management of multiple virtual channels. A virtual channel is used to add functional enhancements to the client independent of the ICA protocol. The virtual channel is a session-oriented transmission connection that can be used by the application layer code. The ICA virtual channel COMMAND protocols include: ThinWire, Printer Mapping, and Drive Mapping.
Thinwire--is used to transmit presentation commands to the client workstation from Windows applications running on the application server. It is designed to use low and width connections between the server and the workstation by using such techniques as:
Printer Mapping--is a virtual channel protocol for the transmission of printer data to the client workstation.
Drive Mappinq--is a virtual channel protocol for the transmission of file system functions between the application server and the client workstation.
FIG. 4 shows the Citrix Systems WinStation 100 and WinFrame.TM. Application Server 200 Communications Stack architecture as a set of component definitions. WinStation 100 is a system component capable of displaying application data and transmitting application input data to the server. The WinStation assumes many forms such as a simple text terminal, a personal computer (PC) emulating a terminal, or a PC running a program (or terminal) that implements the ICA protocol. The functionality of the WinStations and the method of communicating with the server may differ but the architecture shown in FIG. 4 accommodates these differences.
The architecture of FIG. 4 is defined in terms of the protocol layers and their specific responsibilities. At the top of both Application server 200 and WinStation 100 are the respective data sources 210 and 110. In the case of unit 110, a display screen, keyboard, and mouse are shown and function as both a data destination and data source. As previously mentioned, the WinStation 100 may take on a variety of configurations depending on the user needs. The protocol layers are defined as follows.
WinStation Driver (WD) 10 is responsible for interpreting the data stream generated by the WinStation or Application Server. The WD is tailored to each WinStation: it is different for each type of workstation (e.g. a dumb terminal or an ICA terminal).
Protocol Driver (PD) 20 is a communications layer added to the protocol stack for preparing the data to be transmitted to the corresponding WinStation or Application Server. Because all PDs support the same interfaces, each PD can be inserted or removed from the stack in accordance with the needs of each connection. The order in which the Pds are stacked is controlled by the configuration process.
Transport Driver (TD) is a PD for interfacing the stack to the system provided transport service 300 and is tailored to the type of transport service being used by each WinStation.
Protocol Advertiser (PA) 50 is used by each Application Server for broadcasting that a particular Application Server is on-line and functioning. In this way, a WinStation, using the same transport service, may be made aware its availability.
Protocol Listener (PL) 40 provides an Application Server with the capability to listen for connection requests from WinStations.
Name Resolver (NR) 30 is unique to the type of network to which the WinStation is connected, provides network name-to-address translation.
Name Enumerator (NE) 31 is unique to the type of network to which the WinStation is connected and provides enumeration of all on-line Application Servers on the network.
Virtual Driver (VD) 60 is for running the virtual channel protocols as defined in the ICA. The VD supports a generic set of interfaces that are accessible through system Application Protocol Interfaces (APIs) and communicates with the WD through a special interface.
The Application Server 200 of FIG. 4 includes a Win32 Subsystem 210 for the management of an associated client WinStation for which application services are to be provided. As shown in FIG. 5, subsystem 210 includes the Client Server Runtime Subsystem (CSRSS.EXE) Process 230 and Protocol Service Process 240. Process (CSRSS.EXE) 230 controls WinStation Driver Stack 220, a dynamic linkable library (DLL) of protocols by creating the control datastream needed to control the Win-Station being accessed. WinCon Server 231 contains all the console (text window) code and APIs. WD Stack 220 includes WD 10, Pds 20, and TD 21, each of which is a DLL driver.
ThinWire Driver 60 is controlled by Graphical Device Interface (GDI) Server 233 and User Server (USER) 232. GDI Server 233 is the graphics portion of the Win32 subsystem that contains all of the graphics code and APIs. USER 232 is the non-graphics portion of the Win32 subsystem that contains the remaining APIs not contained in WinCon Server 231 or GDI 233.
Protocol Service Process 240, controls PL 40 and PA 50 for effecting a connection between the Application Server and the WinStation requiring service. A PL 40 and PA 50 pair is provided for each type of transport that is supported by the system. The PA 50 broadcasts the Application Server's availability on a network while the PL 40 listens for service requests from WinStations on a network. The WD interface of 5WD Stack 220 provides WinCon Server 231 with display function information, display mode control, and session connect/disconnect information for handling full screen text transmission and WinStation initialization. Keyboard and mouse input is delivered to WinCon Server 231 through the WD interfaces. Each WD maintains a FIFO (first-in, first-out) queue for mouse and keyboard input events. A raw input thread (RIT) in process CSRSS takes its input events from this queue.
The WD Stack 220 is defined by a configuration utility named WINCFG. When a WD is defined or when the Win32 Subsystem is started, the DLLs are loaded. FIG. 6 shows the Win32 Subsystem stack components. The PD 20 and TD21 components are as previously described. The WinStation Drivers (WDs) include: ASCII terminal WD for terminals like the DEC VT420 from Digital Equipment Corp. and the Citrix ICA 3.0 WD.
ICA WinStation, a DOS (disc operating system) program for connecting to and communicating with the Application Server using the ICA protocol, is modular and can be dynamically configured and customized with different user interfaces and optional virtual channel capabilities. FIG. 7 is a graphical representation of ICA WinStation 110 that shows ICA WinStation 110 as an executable (.EXE) DOS program that includes User Interface (UI) 111 and Libraries (.LIB) 112 operating on an assortment of DLLs that are run-time loaded and linked. The Libraries can be linked with the User Interface and DLLs to provide system independent interfaces and ease in porting to non-DOS platforms.
UI 111 is the master controller of the ICA WinStation and has responsibility for:
In order to make a connection to a specific application server, UI 111 maintains configuration information for the connection that includes any name-to-address translation data and a list of protocol stack components (Pds and TD) and protocol parameters required. When an Application Server is selected by the user, the UI loads the appropriate stack components and passes the user selected parameters to the Application Server based upon the configuration data. Configuration Libraries (CFGs), based on Initialization (.INI) files, are used to simplify the loading and linking process. The connection process is initiated by a UI call to the ICA WD 10 at the top of the stack with a connection initiation command. The connection process is asynchronous.
UI 111 starts its polling loop by keying off the connection status that is returned. Once the connection status is established, UI gives up focus (i.e. ownership of the key-board, mouse, and display screen) to the WD. The UI remains the master and continues to run the polling loop. WD gives up focus when the connection is broken.
While a connection exists, UI 111 can query statistics and error conditions and, can also terminate the connection. If a connection is broken, UI 111 is responsible for cleaning-up by unloading all of the stack components.
There are four .INI files associated with UI 111:
Winstation Libraries 112, a set of run-time libraries that simplify customization of components, includes:
These libraries are directly linked to by the UI.EXE and are accessible to the DLLs indirectly through the DLL interface process.
ICA WD 10, when it has focus, controls the presentation of a specific WinStation protocol on the local screen display and also manages the communication of the keyboard and mouse inputs to the Application Server. Focus is given to ICA WD 10 by UI 111, as previously described.
ICA WD 10 gets its protocol packets from the topmost PD on PD stack 20. When ICA WD 10 links with this PD, it registers an input processing entry point. This entry point is called when a data packet is available. When ICA WD 10 needs to write data, it calls the PD using a PD write function.
ICA WD 10 also responds to the polling function of UI 111 and passes it on to lower stack layers. State data is reported by this method so that, for example, if a lower layer detects that a connection is broken, this status information is passed up to UI 111 through the return codes of the polling functions.
ICA WD 10 also provides a general purpose virtual channel capability represented by the set of virtual channel drivers (VDs) 60 described below.
ICA WD 10 provides a set of Application Program Interfaces (APIs) that includes:
All protocol drivers (Pds) 20 have the same interfaces and are dynamically loaded and linked in the same manner by UI 111. Also, a PD may be added or removed from the configuration without changing the underlying code.
Because of some interdependencies, Pds 20 must be loaded in a specific order, e.g. the Compression PD requires the framed packets of the framing PD. The WinStation includes the following optional Pds:
The Wds and Pds each provide a set of Application Program Interfaces (APIs)that includes:
The Transport Drivers (TDs) are similar to the Pds, i.e. the top interfaces are the same and TD loading, linking, and polling are done in the same way. The Tds differ from the Pds because the bottom interface of each is for a specific transport service. For example, the DOS IPX TD is programmed for the Novell IPX DOS INT for reading and writing packets over the underlying IPX network.
The WinStation client includes the following TDs 20:
The TD APIs are similar to those listed for the Pds/Wds above.
Name Resolver (NR) 30 is a DLL module for providing network name-to-address translation of a selected application server to UI 111 of FIG. 7. NR 30 specific APIs include: Load(), NrUnload(), NrOpen(), NrClose(), NrInfo(), NrPoll(), NrNameToAddress(), and NrErrorLookup().
Name Enumerator (NE) 31 of FIG. 7 is a DLL module for enumerating all available application servers on the network. NE 31 specific APIs include: Load(), NeUnload(), NeOpen(), NeClose(), NeInfo(), NePoll(), and NeEnumerate().
Virtual Channel Driver (VD) set 60 are directly connected to ICA WD to allow application level communication to be multiplexed with the display protocol. The set of Vds support the following functions:
VD set 60 includes the following APIs: Load(), VdUnload, VdOpen, VdClose(), VdInfo(), VdPoll(), VdQueryInformation, and VdSetInformation().
Scripting 32 (FIG. 7) is an optional DLL that is an extension of UI 111 for prerecording keystrokes and responses to display screen output for automating some user operations.
Because the application server and the client (user) workstation are generally physically separated and are only linked by a transport mechanism for communications that is of lower bandwidth than that required to directly support the workstation display if it were part of the application server's host system, it is highly desirable to have an efficient method to send graphical data and control messages from the application server to the workstation. This objective requires the use of bandwidth compression encoding techniques at the application server for more efficient use of the common transport system in supporting the illusion that the application is being executed locally.
The use of bandwidth compression techniques for the transmission of text data does not, per se, remove the need to recreate the original data (and bandwidth) required for driving the workstation display. The original bandwidth requirement obtains after the reduced bandwidth encoded message is expanded to the original form required to drive the work station display. For example, the graphical instructions could be encoded by using a code book in which each complex graphical instruction is represented by a simpler numeric code. Upon receipt of the coded graphical data, each numeric code would be decoded at the workstation by entering a copy of the code book using an address corresponding to the numeric code and retrieving the corresponding complex graphical instruction.
The ability to efficiently communicate graphical text data in the form of glyphs (or bit patterns that represent pixel on/off states) is essential for enabling the user to perceive a responsive and timely graphical text display at the workstation even though the application code is executing remotely in a processor that is separated by a low bandwidth transport system.
Prior art techniques for reducing the bandwidth required for the transmission of glyphs has achieved bandwidth reduction by transmitting a text string that includes an ASCII code character for each character of the text plus the font type, size, style, and color. This requires that the receiving workstation have a glyph memory for storing each glyph pattern for each text character for each font type (e.g. Helvetica), for each font size (e.g. 30 points) and for each style (e.g. Italic), required for the session. Typically, 500K bytes of storage is required to store a given font set of a single size and style.